Bloque 3.1 · 25 min

Transformación del modelo E-R al modelo relacional

El modelo Entidad-Relación representa el diseño conceptual de una base de datos. Sin embargo, los SGBD no trabajan directamente con diagramas E-R, sino con tablas relacionales.

Transformar un modelo E-R significa convertir entidades, atributos y relaciones en estructuras SQL reales.

Objetivo de la transformación

  • Convertir entidades en tablas.
  • Convertir atributos en columnas.
  • Transformar relaciones en claves foráneas.
  • Aplicar restricciones de integridad.
CREATE TABLE Alumno (
  id_alumno INT PRIMARY KEY,
  nombre VARCHAR(100),
  apellidos VARCHAR(100)
);
El modelo conceptual es la idea. El modelo relacional es la implementación lógica lista para SQL.
Los SGBD modernos siguen usando el modelo relacional propuesto por E.F. Codd.
¿Qué transforma el modelo E-R en el modelo relacional?
Bloque 3.2 · 20 min

Entidades → Tablas

Cada entidad fuerte del modelo E-R se transforma en una tabla. Sus atributos pasan a convertirse en columnas.

Entidad E-R Tabla relacional
Alumno tabla alumno
Profesor tabla profesor
Producto tabla producto 
CREATE TABLE Profesor (
  id_profesor INT PRIMARY KEY,
  nombre VARCHAR(100),
  especialidad VARCHAR(100)
);
El atributo identificador del modelo E-R se convierte en PRIMARY KEY.
No todas las tablas tienen el mismo propósito: cada una debe representar una entidad concreta.
¿En qué se transforma una entidad fuerte?
Bloque 3.3 · 30 min

Relaciones: claves foráneas o tablas intermedias

Relaciones 1:N

Las relaciones uno a muchos se implementan mediante claves foráneas. 

CREATE TABLE Asignatura (
  id_asignatura INT PRIMARY KEY,
  nombre VARCHAR(100),
  id_profesor INT,
  FOREIGN KEY(id_profesor)
  REFERENCES Profesor(id_profesor)
);

Relaciones N:M

Necesitan una tabla intermedia. 

CREATE TABLE Matricula (
  id_alumno INT,
  id_asignatura INT,
  nota DECIMAL(4,2),
  PRIMARY KEY(id_alumno,id_asignatura)
);
Una relación muchos a muchos nunca se implementa directamente.
Tipo Implementación
1:N Foreign Key
N:M Tabla puente
¿Cómo se implementa una relación N:M?
Bloque 3.4 · 20 min

Atributos multivaluados o compuestos

Una columna no puede almacenar listas ni conjuntos.

Problema

telefonos = "600123123,677888999"

Esto viola la atomicidad.

Solución

CREATE TABLE Telefonos_Cliente (
  id_telefono INT PRIMARY KEY,
  telefono VARCHAR(20),
  id_cliente INT,
  FOREIGN KEY(id_cliente)
  REFERENCES Cliente(id_cliente)
);
Cada teléfono se almacena en una fila independiente.
Los atributos multivaluados suelen generar problemas de mantenimiento.
¿Qué ocurre si guardamos varios teléfonos en una misma columna?
Bloque 3.5 · 30 min

Restricciones de integridad

Integridad de entidad

Las claves primarias no pueden ser nulas ni repetidas.

Integridad referencial

Las claves foráneas deben apuntar a registros existentes.

Integridad de dominio

Cada columna acepta solo valores válidos. 

CREATE TABLE Alumno (
  id_alumno INT PRIMARY KEY,
  edad INT CHECK (edad >= 0)
);
Tipo Función
Entidad Evita PK duplicadas
Referencial Garantiza relaciones válidas
Dominio Valida datos
Eliminar claves foráneas puede generar registros huérfanos.
¿Qué garantiza la integridad referencial?
Bloque 3.6 · 20 min

Normalización: 1FN, 2FN y 3FN

La normalización organiza las tablas para reducir redundancia y evitar anomalías.

Objetivos

  • Eliminar duplicidades.
  • Mejorar integridad.
  • Evitar inconsistencias.
  • Facilitar mantenimiento.
Una base de datos mal normalizada puede repetir nombres, direcciones o productos cientos de veces.
Las tres primeras formas normales son suficientes para la mayoría de sistemas.
¿Cuál es el objetivo principal de la normalización?
Bloque 3.7 · 25 min

Primera Forma Normal (1FN): Atomicidad

La 1FN exige que cada columna tenga valores atómicos.

Incorrecto

telefonos = "600111111,677222222"

Correcto

id_cliente | telefono
1           | 600111111
1           | 677222222
Cada intersección fila-columna debe contener un único valor.
¿Qué exige la 1FN?
Bloque 3.8 · 25 min

Segunda Forma Normal (2FN): Dependencia total

Todos los atributos no clave deben depender completamente de la clave primaria. 

Pedidos(
  id_pedido,
  id_producto,
  nombre_cliente
)

nombre_cliente depende solo de id_pedido, no de toda la clave compuesta.

La solución es separar Cliente en otra tabla.
La 2FN afecta sobre todo a tablas con claves compuestas.
¿Qué elimina la 2FN?
Bloque 3.9 · 25 min

Tercera Forma Normal (3FN): No dependencias transitivas

Ningún atributo no clave debe depender de otro atributo no clave. 

Empleado(
  id_empleado,
  nombre,
  id_departamento,
  nombre_departamento
)

nombre_departamento depende de id_departamento, no directamente de la PK.

Solución

Departamento(
  id_departamento,
  nombre_departamento
)
Cada tabla debe representar una única entidad lógica.
¿Qué elimina la 3FN?
Bloque 3.10 · 30 min

Forma Normal de Boyce-Codd (BCNF)

BCNF es una versión más estricta de la 3FN.

Regla principal

Todo determinante debe ser una clave candidata. 

camion → conductor

Si camion no es clave candidata, la tabla viola BCNF.

BCNF elimina dependencias funcionales anómalas.
Se utiliza especialmente en sistemas críticos.
¿Cuál es la regla fundamental de BCNF?
Bloque 3.11 · 20 min

La dependencia funcional

Existe dependencia funcional cuando un atributo determina otro. 

id_departamento → jefe_departamento

Para cada departamento existe un único jefe.

Importancia

  • Detectar redundancias.
  • Aplicar normalización.
  • Identificar anomalías.
Las dependencias funcionales son la base matemática de la normalización.
¿Qué significa A → B?
Bloque 3.12 · 20 min

Relación entre BCNF y 3FN

3FN BCNF
Permite algunas excepciones No permite excepciones
Más flexible Más estricta
Muy utilizada Sistemas críticos
Toda tabla en BCNF cumple 3FN, pero no toda tabla en 3FN cumple BCNF.
¿Qué relación existe entre 3FN y BCNF?
Bloque 3.13 · 20 min

Ventajas y desventajas de BCNF

Ventajas

  • Coherencia absoluta.
  • Menos inconsistencias.
  • Mantenimiento más sencillo.
  • Integridad más sólida.

Desventajas

  • Más tablas.
  • Más JOINs.
  • Consultas más complejas.
Más normalización NO siempre significa más rendimiento.
A veces se desnormaliza parcialmente para mejorar velocidad.
¿Cuál es una desventaja habitual de BCNF?
Bloque 3.14 · 30 min

Ejemplos de estudio

Tienda online

El sistema original repetía datos de clientes y productos.

Después de normalizar

  • Cliente
  • Producto
  • Pedido
  • Detalle_Pedido
CREATE TABLE Detalle_Pedido (
  id_pedido INT,
  id_producto INT,
  cantidad INT
);

Empresa de transporte

La dependencia: 

camion → conductor

provocaba violación BCNF.

Solución

Camiones(camion, conductor)
Rutas(camion, ruta)
La normalización evita actualizar múltiples filas innecesariamente.
¿Qué problema resuelve BCNF en el ejemplo del transporte?
Bloque 3.15 · 20 min

Consejos profesionales

  • Normaliza antes de insertar datos reales.
  • Detecta redundancia desde el diseño.
  • Usa nomenclatura coherente.
  • Documenta relaciones y dependencias.
  • Valida claves foráneas periódicamente.
  • Prueba el esquema con datos reales.

Herramientas recomendadas

  • MySQL Workbench
  • dbdiagram.io
  • pgModeler
  • DBeaver
  • Oracle SQL Developer Data Modeler
En proyectos reales, modeladores y desarrolladores backend trabajan juntos.
No modelar antes de programar suele generar errores estructurales graves.
¿Qué herramienta permite generar scripts SQL desde diagramas?
Material para ayudarte a estudiar bases de datos. Mucha suerte.